This invention relates to computer-based systems and methods for generating meaningful symbolic debug information in translator-based software compilation systems.
FIG. 1 shows a structural diagram/functional flowchart of a conventional translator-based compilation system 100. In FIG. 1, rectangles represent software modules/processes and ovals represent the inputs and outputs of the software modules/processes.
As shown in FIG. 1, the conventional translator-based compilation system 100 includes a translator 106, a compiler 114, a linker 128, and a debugger 122.
The translator 106 translates a source code 102 (in the C++ programming language, for example) to an intermediate source code 110 (in the C programming C language, for example). The compiler 114 compiles the intermediate source code 110 and generates object code 124 and debug information 126. The object code 124 and the debug information 126 are stored in an object code file 118.
A linker 128 links the object code file 118 with other object code files 134 to produce an executable file 132. The executable file 132 contains the object code 124 and the debug information 126.
The debug information 126 is very important as the debug information 126 can be used to locate and correct errors in the source code 102 (that is, to "debug" the source code 102). Specifically, under the direction of a user (not shown in FIG. 1), the debugger 122 receives the executable file 132 containing the object code 124 and debug information 126 and uses the debug information 126 to debug the source code 102.
However, in conventional translator-based compilation systems 100, the compiler 114 is not capable of generating accurate and complete debug information 126 for the source code 102. This is true because much of the information about the structure and content of the source code 102 is lost in translating from the source code 102 to the intermediate source code 110.
Therefore, the debug information 126 generated by the compiler 114 cannot be used to efficiently and effectively debug the source code 102.
One prior attempt at solving this problem involved a "do nothing" approach. Under this prior solution approach, the debugger 122 would read the debug information 126 generated by the compiler 114 and optionally try to "demangle" variable and function names and to use heuristic methods to re-create a crude approximation of the original data structures, etc., in the source code 102.
However, under this prior approach, even if the debugger 122 could display the original source code 102, the debugger's 122 diagnostic output would be incomplete at best, and incomprehensible in many cases. Also, in most cases, the user would have to manually specify the "mangled" variable and function names from the intermediate code 110 to the debugger 122 in order to inspect variables and functions.
Another prior attempt at solving this problem involved a "go backwards" approach. Under this prior solution approach, attempts would be made to transform the debug information 126 to reconstruct the original data structures, etc., in the original source code 102. This modified debug information would then be presented to the debugger 122.
However, under this prior approach, the modified debug information would likely be incomplete and even possibly incorrect, because it would not always be possible to reconstruct the source code 102 from the intermediate source code 110.